It’s been a tough couple of years for cybersecurity strategists and practitioners. In 2021, supply chain attacks on Kaseya, Solar Winds, Accellion and other hardware and software providers sowed doubt into their long-standing assumptions of trust. Ransomware piggybacked on some of these exploits to drive their severity and urgency (see Kaseya, again). Even when these attacks weren’t embedded deep in tech supply chains, some 2022 attacks were still potent enough to disable entire governments: Conti’s attack on Costa Rica government offices and an unnamed hacker’s ransom-driven takedown of IT systems in Bernalillo County in New Mexico—home to Albuquerque, scores of thriving companies and one of the state’s largest prisons—are just a few examples.
But good defenders rethink, regroup and revise their strategies.
In 2022, NIST finalized updates to Security and Privacy Controls for Information Systems and Organizations, its most foundational framework for securing information systems. Revision 5 of SP 800-53, or “Rev 5” as it’s more generally known, is designed to update and strengthen a set of controls that were first codified as “Rev 1” back in 2005.
These updates were needed to defend against lower and slower and deeper attacks, particularly against cloud-based technologies, applications and services. For eighteen years this framework has been the backbone of all federal cybersecurity plans, most private sector cybersecurity programs and a host of other mandates and regulations. Rev 5 adds 66 new base controls, 202 new control enhancements, 131 new parameters and a whole new control family to existing controls. (A good review of Rev 5 changes can be found here.)
Which brings us to FedRAMP.
The Other Shoe Drops
The Federal Risk and Authorization Management Program is a broad US compliance program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP has relied, since its inception, on SP 800-53 as a library of system controls that can be assessed and measured through the FedRAMP process. As the FedRAMP program says of itself, “FedRAMP uses the National Institute of Standards and Technology’s (NIST) guidelines and procedures to provide standardized security requirements for cloud services.”
Effectively, SP 800-53 provides a lingua franca. It’s a common language through which all parties—cloud service providers, agencies, auditors, 3PAOs—can go about the work of “assessing, authorizing, and monitoring” the cloud -based applications and services used by the federal government agencies and departments.
Anyone with a vested interest in FedRAMP knew that when the FedRAMP office aligned its plans and procedure to Rev 5 there would be a tidal wave of new perspectives, actions and requirements. That day came on May 30 2023 when the FedRAMP blog announced ”Rev. 5 Baselines Have Been Approved and Released!”
To paraphrase our president from when he was Obama’s VP in 2010: this is a big deal. It’s the “other shoe” from changes to SP 800-53 that have been percolating since 2020 and even earlier.
The specific details of alignment of FedRAMP to Rev5—what does it impact? who needs to be informed? how do we interpret the changes and their timelines? —are crucially important. They’re both material and critical to the three hundred-plus CSPs with products and services already ATO’d, to the hundred or so products that are In-process or Ready, and to the 30,000 application and service providers who might like to sell their wares to government agencies and departments.
This three-part blog series shares Anitian’s perspective on:
- A brief overview of the move from CIS Level 1 benchmarks to STIGs (Security Technical Implementation Guides) for CM-6 Configuration settings (this blog post)
- A deep-dive into some of the biggest changes: new requirements for Privacy Controls, the addition of new Supply Chain controls and requirements, new requirements for encryption of Data-at-rest and Data-in-transit (Blog Post #2)
- A review of timelines, next steps and required action for all parties, as well as some advice from Anitian compliance experts (Blog Post #3)
With that foreshadowing done, let’s see what’s in store.
Summary of Changes
The staff at Anitian picked five topic areas to focus on in this blog series. These aren’t in any specific order and aren’t inclusive of all the changes in the Rev 5 sea change.
- Move from CIS Level 1 benchmarks to STIGs for CM-6 Configuration settings: (see our unpacking below)
- The addition of supply chain controls and requirements: new control family, Supply Chain Risk Management (SR) aims to address the risks “associated with the acquisition, development, and maintenance of information systems and components associated with third-party and vendor services, products, and supply chains.” Additionally, a handful of new controls have been added to existing families to address these risks as well.
- The addition of Privacy controls: FedRAMP is now requiring data privacy to be considered across a swath of existing controls and control families, including Awareness & Training, Configuration Management, as part of the SDLC, among others.
- Encryption strengthening: New requirements for FIPS-validated or NSA-approved encryption of all data-at-rest, inclusive of backups and archives, as well as data-in-transit which means into, through, or out of an ATO boundary.
- The addition of traffic analysis and covert exfiltration requirement for Moderate systems: FedRAMP is requiring that Moderate system now analyze outbound communications at the external system boundary and any subnetworks or systems to detect covert exfiltration of information.
Let’s take a look at what some of these changes mean.
The Move to DISA STIGs
It’s sometimes difficult to clarify the relationship “baselines and benchmarks”—like Center for Internet Security (CIOS) benchmarks, or the US Department of Defense Systems Agency (DISA) Security Technical Implementation Guides (STIGs)—from “regulations and programs” like FedRAMP.
But try this analogy:
- When you drive, you take advantage of a complex infrastructure made up of roads, highways, curbs, traffic signals, signage, lighting…even the asphalt or concrete surface you’re driving over is part of the infrastructure. That infrastructure and the material it’s created from are catalogued in much the same way baselines catalog our underlying operating systems, application libraries, network controls, and cloud components. The logic of that infrastructure is captured in benchmarks and baselines.
- As you’re driving, you’re constrained by rules that tell you how you’re supposed to interact with all that infrastructure: obey posted signs; understand speed limits; know which types of vehicles can use certain types of roads and which can’t; understand concepts like “right of way” and the unique privileges of emergency vehicles. These rules are captured in regulations like FedRAMP.
STIGs and CIS benchmarks are the two primary third-party baselines adopted across public and private organizations, and industry standards like NIST 800-53 (the underlying framework for the FedRAMP program) use DISA STIGs and CIS benchmarks to define the best way to configure security controls. Generally speaking, CIS is used commercially, and DISA STIGs are used for military and defense computing systems.
This made sense in a past where equipment designed for military use was vastly different from similar equipment used in commercial activities. But in the digital transformation era such specialization has largely ceased. Rather than being developed from the ground up for specific uses—for example, how NIPRnet and SIPRnet were protocols that evolved to transmit unclassified and classified information—modern cloud technologies are developed for use along a continuum. This continuum might have public-sector, unclassified use on one end and defense-related, classified usage on the other end, with the differences being how “ratcheted down” and rigorous each control could be.
Fast-forward to FedRAMP’s recent changes: Where in the past the FedRAMP office has accepted CIS baselines for documentation of security control configurations, the stated FedRAMP preference is now to use DISA STIGS to capture those details. Hypothetically, this might allow a critical cloud-based service for privileged access control, take CyberArk for example, to seek ATO for FedRAMP using much of the same evidence and supporting references—benchmarks and baselines—it needs for equally rigorous Department of Defense IL-4 approvals.
“FedRAMP is getting A LOT of feedback.”
While FedRAMP says the use of CIS is acceptable if STIGS are not available, use of CIS benchmarks does require an exception to be filed (at this point). As one Anitian compliance expert pointed out: “This move has proved highly contentious and FedRAMP is getting A LOT of feedback on this as implementing STIGs can be expensive and technically difficult to understand.”
If the goal is to make secure cloud-based applications and services available across civilian and defense marketplaces, this move to DISA STIGs as a foundation makes sense. This kind of upleveling is a “rising security tide” that can “lift the defensive posture of all boats,” to mangle a useful expression. Practically, having a single consistent path to ATO for either civilian or defense usages could mean increased availability of innovative tools and services to help a market that is already hungry for cloud-based tools. And they might get to users faster.
Those are “Pros” on this move. As a respected strategist/practitioner we follow on LinkedIn has commented, “now the lift from FedRAMP to DoD IL 4/5 was just made significantly easier. Having to go from CIS to STIGS can be a really painful process.” (Thanks to John Allison of Devo Security.)
One big “Con” that could potentially counter these Pros: by any measure, STIGing is hard, and raising the bar to require conversion from CIS to STIG baselines might be a proverbial “bridge too far” for some CSOs and keep their products and services out of federal markets entirely. Time will tell whether the opportunities for CSPs outweigh the added effort and cost that comes from meeting the rigor of DISA baselines and benchmarks.
This change is a considerable shift from the CIS-oriented prevailing wind that has steered the FedRAMP ship since 2011. While there’s still a tremendous amount of discussion and debate that needs to occur, it seems clear that:
- The FedRAMP Program Management Office (PMO) is intent on upleveling the rigor of many parts of its program.
- Acknowledging and maintaining a seamless continuity between FedRAMP’s moderate-level systems and high-level systems within the Department of Defense (DoD) at IL-4 It is essential. The transition between these levels should be made more accessible for Cloud Service Providers (CSPs) while ensuring that the security posture of each individual offering remains uncompromised.
We’ll come back in Parts 2 and 3 of this series to discuss what these changes mean for supply chain risk management and encryption controls. Send us your questions and comments and check out the Anitian white paper on the Rev 5 transition.
